When users browse pages, they sometimes encounter a situation where they need to log in to a website before they can continue to browse pages on the site. If a user is detected as not being logged in, the browser will be redirected to the login page. After login is completed, the browser returns to the original page that the user wanted to browse. This process is sometimes referred to as a login jump. FIG. 1 is a diagram illustrating an example network processing flow for a login jump operation. The user has not logged in. The client browser is used to access the page that requires login. The client browser issues a hypertext transfer protocol (HTTP) request. The server receives the page requested by the user, e.g., the website server/page server, etc. After the server receives the requested page, it will assess whether the user has logged in. If the user has not logged in, the server regards the page address of the user-requested page as a parameter and externally redirects the request to the login server. That is, the server takes the universal resource locator (URL) as a parameter and externally redirects the request. After his request is redirected to the login server, the user completes the login process. Then, after the user logs in, the browser is externally redirected back to the user-requested web page. Lastly, the results from the requested web page are returned to the client browser, and the page is accessed.
In actual implementation, the browser is limited as to the length of the URL of the web page. That is, the accessed URL cannot be too long. The majority of existing websites have their own login servers which centrally process the login actions of website users. When the web page that a user needs to access requires login prior to access, the website will generally redirect the browser to the login server. After the user completes the login action, the server redirects the user's browser to the requested page (the actual/original page requested by the user). In order to complete this transfer, the user's browser, when being redirected to the login server, must carry the address of the page that was originally to be accessed so that the login server knows to which address the browser should be sent back after completing login. If the URL of the original page to be accessed by the user is very long and serves as a parameter, and it will be necessary to append the original URL (represented as a) to a new URL (represented as b), i.e., a+b=ab, the browser's URL length restriction may then be exceeded. In this case, the browser's buffer will not be able to properly keep the resulting new URL (ab), and the registration server cannot acquire the entire URL of the corresponding original page. Subsequently, the login server's redirecting back to the user-requested page may fail, or the login may fail. Thus, even if it is possible for the browser to arrive at the login page, the login may fail because of incomplete information; or the browser may fail to jump back to the original page after completing the login. Such failures can severely impact the user's experience.
In summary, in existing systems, a client sometimes experiences login failure or redirection failure because the redirected address used for access is too long.